In my view the thing that LFS needs most urgently is a better collision system. The impossible collisions that are happening quite often are spoiling so many races and making so many people angry. I know collision with barriers is probably improved in the upcoming patch, but I guess cars can still fly like crazy, sometimes after just a slight touch. Better graphics, tyre physics – cool. But it is the collisions that have often physically clearly impossible results. For me, that's where LFS needs serious improvements.
Interesting question! But I do not think there can be FE4X.pth covering all FE roads. I would say a PTH file must represent just one path without splits and joins, also with incremented node numbers. So I think there are two questions:
1) Is a PTH file all that the LFS engine needs to assess car positions in race?
2) Is it possible for LFS to load custom PTH files?
Well, overall, I think this is rather complicated, because the same PTH files must be guaranteed to be available on all clients, that is if race positions and flags are not handled only by the server. That would make things much easier, but I do not think that is the case.
1) Is a PTH file all that the LFS engine needs to assess car positions in race?
2) Is it possible for LFS to load custom PTH files?
Well, overall, I think this is rather complicated, because the same PTH files must be guaranteed to be available on all clients, that is if race positions and flags are not handled only by the server. That would make things much easier, but I do not think that is the case.
Hmm, well, isn't for example the _Reversed part of the layout name extraneous? After all, that Y in track name says it already.
Mostly, I think we'll see in time what is possible, because I'm not sure what you mean by "a tracker that delivers it into LFS". Maybe you mean an intermediate InSim application that will connect directly to LFS and that will process the open layout tracks in a special way, adding node/position data into standard LFS packets, sending them then over to TV Director or anything else?
I guess that would be possible, but I suspect you'll need new 4-char track codes to have the new tracks "properly" recognized. My guess is TV Director would accept ASAR as a track name, while it will not understand what AS13R is. In fact this will not be even communicable. But that's only a guess, I have no idea what info the TV Director uses and how flexible it is in recognizing new tracks.
Airio/AIRW are very flexible in this thing, but they expect 4 chars max as a track name. Hence my suggestion of using letters instead of numbers for the new layout tracks. 4 chars is a LFS standard for tracks, just as 3 chars are standard for car names. I think we should stick to the standards to make it all as much transparent as possible.
Is it actually available?
Mostly, I think we'll see in time what is possible, because I'm not sure what you mean by "a tracker that delivers it into LFS". Maybe you mean an intermediate InSim application that will connect directly to LFS and that will process the open layout tracks in a special way, adding node/position data into standard LFS packets, sending them then over to TV Director or anything else?
I guess that would be possible, but I suspect you'll need new 4-char track codes to have the new tracks "properly" recognized. My guess is TV Director would accept ASAR as a track name, while it will not understand what AS13R is. In fact this will not be even communicable. But that's only a guess, I have no idea what info the TV Director uses and how flexible it is in recognizing new tracks.
Airio/AIRW are very flexible in this thing, but they expect 4 chars max as a track name. Hence my suggestion of using letters instead of numbers for the new layout tracks. 4 chars is a LFS standard for tracks, just as 3 chars are standard for car names. I think we should stick to the standards to make it all as much transparent as possible.
Is it actually available?
Last edited by EQ Worry, .
True, but on the other hand I do not see any point in trying to make every single track configuration, just because it is maybe possible (some of them are really weird). But there are new AS or KY tracks worth standardizing, it seems to me. For example appended is a rough combination of AS2 and AS3 producing a track that's called AS8 in the 1st posts here (and which I'd rather call e.g. ASA, to keep the character count).
Last edited by EQ Worry, .
Righto! 
Or something else, maybe also by using new special PTH files that could be mostly compiled from the existing ones... Because I've been already editing the PTH files for the AIRW purposes, I guess I could do that relatively easily.
Or something else, maybe also by using new special PTH files that could be mostly compiled from the existing ones... Because I've been already editing the PTH files for the AIRW purposes, I guess I could do that relatively easily.A few notes:
1) Currently, track names can have max 4 characters - 2 chars describe the site, one number is the actual track version, and optional R shows it is reverse. Naming tracks as e.g. AS13R, using 5 chars, may introduce problems. An option would be not to use numbers, but letters from A to Z. It would be obvious then that ASB is an layout track and ASBR is the reverse version of the same. The LFS limit of max 4 chars in track code would be observed.
2) As you maybe know, the Airio World (AIRW) database already contains some data extending LFSW, such as best/good online clean laps plus personal and world records in some widely used restricted cars (GT2s). Unless something better appears, I intend to extend the AIRW functionality to some agreed-on open layout tracks, so that there can be personal and world records. Of course this is limited to Airio PROS versions running on the server, and it would require some more thinking to be sure valid layouts are used. But generally, I think that with some additions this is possible even without track nodes.
3) To have actual race positions shown would be nice. I guess again a mechanism could be developed, either inside Airio or by someone else using his own ideas/tools that would replace the standard LFS list by a new one, but that would require some serious development and thinking about how to reliably assess car positions.
1) Currently, track names can have max 4 characters - 2 chars describe the site, one number is the actual track version, and optional R shows it is reverse. Naming tracks as e.g. AS13R, using 5 chars, may introduce problems. An option would be not to use numbers, but letters from A to Z. It would be obvious then that ASB is an layout track and ASBR is the reverse version of the same. The LFS limit of max 4 chars in track code would be observed.
2) As you maybe know, the Airio World (AIRW) database already contains some data extending LFSW, such as best/good online clean laps plus personal and world records in some widely used restricted cars (GT2s). Unless something better appears, I intend to extend the AIRW functionality to some agreed-on open layout tracks, so that there can be personal and world records. Of course this is limited to Airio PROS versions running on the server, and it would require some more thinking to be sure valid layouts are used. But generally, I think that with some additions this is possible even without track nodes.
3) To have actual race positions shown would be nice. I guess again a mechanism could be developed, either inside Airio or by someone else using his own ideas/tools that would replace the standard LFS list by a new one, but that would require some serious development and thinking about how to reliably assess car positions.
Nodes are like little sectors, numbered as incremented integers in the direction of the race path, from start to finish. I have no idea how could you have nodes on an open site where there is no predefined race path at all.
If I understand correctly, then the IS_REO packet should recognize zero PLIDs as empty places on the grid. Then you could make e.g. positions 3 and 4 empty, while 1, 2, 5, 6 etc. are used by the submitted PLIDs... That would be a nice feature too, if possible.
PS: Awwww, my 1000th post, and I almost missed it...
Last edited by EQ Worry, .
Well, that is really a lot of info already. Personally, I would be happy even with something much simpler considering collisions with objects (including walls, that is important for me), just PLID and maybe type of the object. However, I see no problem having more data than necessary. I might just note that for the collision with another car the CarContact could really contain pedal info (throttle, brake), as Dave suggested earlier.
I might just note that for the collision with another car the CarContact could really contain pedal info (throttle, brake), as Dave suggested earlier.Right.
One minor thing considering InSim versioning. To make use of the new IS_MTC packet possibilities, InSim applications need to know to what kind of server they are connected. Such data are available in the IS_VER packet. But the InSim version contained there in two bytes is not unusable, if it stays at number 4. Would it be possible to increase the InSim version to 5 in this new patch? I know there are no substantial changes, but on the other hand there's no need to keep InSim versions low, is there? (Or maybe use the two bytes for major and minor versioning? But that creates incompatibility.) In any case, parsing the host version from e.g. 0.5Z30 is certainly possible, but not reliable for the future, so raising InSim version would be great...
One minor thing considering InSim versioning. To make use of the new IS_MTC packet possibilities, InSim applications need to know to what kind of server they are connected. Such data are available in the IS_VER packet. But the InSim version contained there in two bytes is not unusable, if it stays at number 4. Would it be possible to increase the InSim version to 5 in this new patch? I know there are no substantial changes, but on the other hand there's no need to keep InSim versions low, is there? (Or maybe use the two bytes for major and minor versioning? But that creates incompatibility.) In any case, parsing the host version from e.g. 0.5Z30 is certainly possible, but not reliable for the future, so raising InSim version would be great...
Great ideas! Now I guess we need to see what will make it into Z29. As always, many seemingly simple ideas are very hard to convert into code, I'm sure.
As always, many seemingly simple ideas are very hard to convert into code, I'm sure.I guess that could be handy. My concerns are that: 1) Reporting every contact with every object may sometimes generate high amount of packets/events. 2) Adding a byte to the existing packet creates incompatibilities. But of course, having info about objects touched, even in normal race, would be good.
Good to hear!
Is there any chance to get a preview Z29 version for private testing of these things? Well, probably not, but had to ask anyway. 
As I see it, the open sites (AS, KY) are a quick way to create new custom tracks using layouts. But there'll be no racing lines, no racing paths, maybe also no nodes, so generally racing on these tracks will have the same limitations as racing on node-less layouts (no flags, no race positions, etc). Creating "official" tracks based on current sites would take much more time and effort on the developers side, also much more testing. I do not know which way this development will go, but I do not see KY4, AS8 as something coming to LFS and LFSW within a reasonable time (months).
Fist of all, thanks, Scawen, for all these updates!
I'll need a bit more time to think about the collision packet and usability of the contained info, but at a first sight it looks really interesting! An algorithm reliably detecting the car causing the crash would not be easy to develop, but I think this addition just makes it possible. I'll try to think about it.
The longer messages are a blast! I would be most happy even with 96 bytes, but 128 is just great.
Moving the traction control bit would be good, just as having the car damage info available (points 3 and 4), but I do not see those two as some pressing matters. If they are easy to add, good. If not, maybe rather add some more usable things. And, as I see it, these would be, starting with the most pressing ones:
1) Not really an InSim feature, but what I miss most in the whole LFS is a (simple) admin command to cancel running kick/ban votes, something like /stopvote or whatever. It will not disable voting, it will just cancel the current vote. InSim apps can then apply various criteria, analyze who is voting against whom, and let the vote go or cancel it. BTW there's no InSim info about kick/ban votes, but the necessary data (what kind of vote it is, who votes, etc.) can be parsed from server messages, so it is not really needed.
2) Include into OutSim or maybe rather into OutGauge an additional bit indicating that Ctrl+Shift is pressed on the client. This is used to change some buttons in LFS (nicknames/usernames), it would be great if also local InSim applications could provide this functionality. All that is needed is this one bit.
These two above I'd love to see in addition to the already provided changes, they'd be extremely useful, especially the vote canceling command. Of course there can be a whole bunch of other improvements, currently I see one more as a useful option:
3) Report somewhere, I guess the standard CompCar used in MCI would be good, so that no new special packet is needed, that the car hit a wall or some other object, maybe even other car, in the elapsed period (since previous MCI). I do not know if this is possible though, if the server has such data actually available. But it would be good for detecting completely clean online laps, similar way HLVC does it for offline laps.
That's it from me. Thanks for considering the proposals. And big thanks for already implementing some of them.
I'll need a bit more time to think about the collision packet and usability of the contained info, but at a first sight it looks really interesting! An algorithm reliably detecting the car causing the crash would not be easy to develop, but I think this addition just makes it possible. I'll try to think about it.
The longer messages are a blast! I would be most happy even with 96 bytes, but 128 is just great.
Moving the traction control bit would be good, just as having the car damage info available (points 3 and 4), but I do not see those two as some pressing matters. If they are easy to add, good. If not, maybe rather add some more usable things. And, as I see it, these would be, starting with the most pressing ones:
1) Not really an InSim feature, but what I miss most in the whole LFS is a (simple) admin command to cancel running kick/ban votes, something like /stopvote or whatever. It will not disable voting, it will just cancel the current vote. InSim apps can then apply various criteria, analyze who is voting against whom, and let the vote go or cancel it. BTW there's no InSim info about kick/ban votes, but the necessary data (what kind of vote it is, who votes, etc.) can be parsed from server messages, so it is not really needed.
2) Include into OutSim or maybe rather into OutGauge an additional bit indicating that Ctrl+Shift is pressed on the client. This is used to change some buttons in LFS (nicknames/usernames), it would be great if also local InSim applications could provide this functionality. All that is needed is this one bit.
These two above I'd love to see in addition to the already provided changes, they'd be extremely useful, especially the vote canceling command. Of course there can be a whole bunch of other improvements, currently I see one more as a useful option:
3) Report somewhere, I guess the standard CompCar used in MCI would be good, so that no new special packet is needed, that the car hit a wall or some other object, maybe even other car, in the elapsed period (since previous MCI). I do not know if this is possible though, if the server has such data actually available. But it would be good for detecting completely clean online laps, similar way HLVC does it for offline laps.
That's it from me. Thanks for considering the proposals. And big thanks for already implementing some of them.
The open tracks really sound rather like cruising, but surely we'll see if it will be possible to race there as well, though with limited data available. If that is possible, I'd certainly want to support some new agreed-on layout-defined tracks through AIRW, scoring unofficial online world records and such things... That is if anyone would be interested in this and Victor will not make it somehow official for LFSW...
Of course I'll try to test/help in any way possible. I'll be watching for that thread...
I am speechless, so far the changes look fantastic! 
I really cannot wait to see it all in action, especially the InSim things (longer messages, collisions [hopefully also with other objects than cars?])! Please allow me just two (really, 2) more wishes very high on my wish list:
1) Add an admin command to immediately cancel the running kick/ban vote. With this simple addition (I hope) the voting could be fully managed by external applications, allowing to apply various criteria to prevent voting abuse. This would be simply awesome!
2) Report, using a single bit in OutSim or OutGauge, that Ctrl+Shift is pressed. Then, double-purpose client buttons could be easily created, showing e.g. nicknames and usernames depending on this bit. It would be a great addition.
I hope these my wishes will come through to you, Scawen. Thanks for all the currently implemented changes, it opens new possibilities! (Well, of course opening BL1R and BL2R to demo people would be a big boost to LFS too, but I do not dare to propose that.)
I really cannot wait to see it all in action, especially the InSim things (longer messages, collisions [hopefully also with other objects than cars?])! Please allow me just two (really, 2) more wishes very high on my wish list:1) Add an admin command to immediately cancel the running kick/ban vote. With this simple addition (I hope) the voting could be fully managed by external applications, allowing to apply various criteria to prevent voting abuse. This would be simply awesome!
2) Report, using a single bit in OutSim or OutGauge, that Ctrl+Shift is pressed. Then, double-purpose client buttons could be easily created, showing e.g. nicknames and usernames depending on this bit. It would be a great addition.
I hope these my wishes will come through to you, Scawen. Thanks for all the currently implemented changes, it opens new possibilities! (Well, of course opening BL1R and BL2R to demo people would be a big boost to LFS too, but I do not dare to propose that.)
Calm down guys, please. I'm the villain here and I accept that role, as perfectly summarized by Hyntty. And that is no sarcasm, I do realize that some things I do are controversial and raising emotions from both ends of the spectrum.
Concerning server copying, Airio allows for just a little customization, so basically all multiclass servers using Airio are bound to look the same and thats true also for demo servers. That's why I really don't think CG copied IHR and MRc copied AA.
Concerning server copying, Airio allows for just a little customization, so basically all multiclass servers using Airio are bound to look the same and thats true also for demo servers. That's why I really don't think CG copied IHR and MRc copied AA.
LOL, OK, Hyntty, thanks for clearing it all up. Ouch, I forgot to mention: No, there's no fan club of mine.
Ouch, I forgot to mention: No, there's no fan club of mine.I'm not really sure about Hyntty's post, I was even consulting this with my best LFS friend, and he said that it was meant sarcastically. But my answer was indeed intended for everyone showing concerns, which were bound to come. I see them as valid ones, I may just say that this all was very exceptional case.
Over the past 2 years many people gave me access to their admin panel or remote desktop when configuring servers/Airio, and of course such access includes server passwords. I have never misused that trust in any way, even when we were having quite some dispute with Samix some weeks ago. (Completely settled now.)
But you're right, I took it too personally, though probably with valid reasoning, but I should have shown more restraint, and just wait for it all to fizzle out, as z-ro puts it. On the other hand, it would be good to have some kind of protection from such attacks, especially since the LFS developers are taking their Two Years' Vacation.
But my answer was indeed intended for everyone showing concerns, which were bound to come. I see them as valid ones, I may just say that this all was very exceptional case.Over the past 2 years many people gave me access to their admin panel or remote desktop when configuring servers/Airio, and of course such access includes server passwords. I have never misused that trust in any way, even when we were having quite some dispute with Samix some weeks ago. (Completely settled now.)
But you're right, I took it too personally, though probably with valid reasoning, but I should have shown more restraint, and just wait for it all to fizzle out, as z-ro puts it. On the other hand, it would be good to have some kind of protection from such attacks, especially since the LFS developers are taking their Two Years' Vacation.
Hyntty, obviously you do not agree with what I did. I might just add that it is indeed very easy to hold high moral grounds, until it involves you personally and 1000s of hours of your work. Then even quite desperate means come into play, especially if they are directly offered. But looking back now, I am perfectly willing to concede that the bans were indeed too desperate measure that I should resist from using.
Samix, as you can see, implementing a feature allowing me to shut down any Airio remotely is quite controversial. I'm really not sure about this. I guess the FREE versions could contain this "feature", specifically mentioned in some usage instructions/agreement. It is, after all, given freely, so I can create/modify usage conditions on the fly. With FULL/PROS versions it is more complicated, and such approach is basically impossible.
Samix, as you can see, implementing a feature allowing me to shut down any Airio remotely is quite controversial. I'm really not sure about this. I guess the FREE versions could contain this "feature", specifically mentioned in some usage instructions/agreement. It is, after all, given freely, so I can create/modify usage conditions on the fly. With FULL/PROS versions it is more complicated, and such approach is basically impossible.
I fully agree with Hyperdrive here. You do not care about those damn demo servers, you don't go there, so you do not care if someone is trying to make damage to them. But try to run some servers for years, taking care every day of many things, giving it all your time and quite a lot of money, and your point of view will change substantially. So, from my perspective it was indeed EXTREMELY disruptive.
FGED GREDG RDFGDR GSFDG